Reusable Specification Components for Model-Driven Development∗

Modern, complex control systems for a specific application domain often display common system design architectures with similar subsystem functionality and interactions, making them suitable for representation by a reusable specification architecture. For example, every spacecraft requires attitude determination and control, power, thermal, communications, and propulsion subsystems. The similarities between these subsystems in most spacecraft can be exploited to create a model-driven system development environment in which generic reusable specifications and models can be tailored for the specific spacecraft design, executed and validated in a simulation environment, and then either manually or automatically transformed into software or hardware. Modifications to software and hardware during operations can be similarly made in the same controlled way, that is, starting from a model, validating the change, and finally implementing the change. The approach is illustrated using a spacecraft attitude determination and control subsystem. 1 Component-Based System Engineering Reuse is clearly a partial solution to the long and costly development problems we are experiencing with complex control systems. The reuse of application software components, however, has had surprisingly limited success in many domains and has, at times, resulted in spectacular losses. In spacecraft, for example, NASA and the European Space Agency have lost billions of dollars and important scientific missions due to software reuse and poorly designed changes to operating software. The question is how to get the benefits of reuse without the drawbacks [12]. The answer may rest in the development level at which reuse is applied. The most problematic reuse has been attempted at the code level, but reuse may be more effective and safe by going back to an earlier development phase in a model-driven development environment. Component-based system engineering (as opposed to component-based software engineering) employs reuse at the requirements and specifications level, where required changes to the reused components are made and validated and the code is then regenerated either manually or automatically. Changes at that level can be made (or at least reviewed) by system engineers and domain experts who are more likely to understand the application’s engineering requirements in depth and less likely to make changes that violate the basic engineering assumptions underlying the system. A basic requirement for successful use of this approach is having specifications and models that include thoroughly documented design rationale and assumptions. For example, although ∗The research in this paper was partially supported by NSF ITR Grant CCR-0085829, by a grant from the NASA Engineering for Complex Systems Program NAG2-1543, and by a grant from the NASA Intelligent Systems (Human-Centered Computing) Program NCC2-1223